Because of its “flood-and-learn” nature, standard Ethernet (IEEE 802.3) is generally unsuitable for network topologies where there is more than one path between any two nodes. The existence of a parallel path creates a loop around which the Ethernet frames circle endlessly, thus overburdening the network. Therefore, Ethernet is best suited to a tree topology rather than a ring. However, ring topologies are desirable for deploying Ethernet in Metro Area Networks where ring topologies are desirable, e.g. for resiliency.
Deployment of large (metro area) Ethernet rings is hindered, however, by the fact that Ethernet rings are prone to endlessly loop unless protocols such as IEEE 802.1D Spanning Tree Protocol (STP) or IEEE 802.1W Rapid Reconfiguration are used to detect and disable parallel branches that create loops. While Spanning Tree Protocol and Rapid Reconfiguration can eliminate loops on Ethernet rings, these protocols introduce recovery lags in the order of tens of seconds, i.e. the time to recover from a fault in the ring is unacceptably high for customers who expect seamless connectivity and undetectable fault correction. In other words, customers expect connectivity to be restored within approximately 50 ms (like SONET does).
A further shortcoming of current Ethernet ring technology as defined in 802.17 is that the MAC-PHY chip that determines which direction to send traffic around the ring is a specialized component where innovation and available bandwidth typically lags other, simpler, Ethernet PHY implementations. Thus, even if all the other components of the Ethernet switches are capable of handling higher rates, as is currently achievable, the ring MAC-PHY chip limits the overall bit-rate of the ring.
Thus, it remains highly desirable to provide a simple, resilient and high-speed virtual ring for frame-based traffic such as Ethernet, particularly for Metro Area Networks.
An additional shortcoming of current network topologies is the unwanted time delay that occurs when, due to a fault in the system, transmitted data packets are returned or “looped back” to the originating source node. While a secondary path is used to handle traffic that can no longer be delivered to its destination via the primary path due to the fault, significant delay time is accumulated due to the time that it takes for traffic to travel to the point of failure and then travel back to its originating node.
Thus, it remains highly desirable to provide a method and system that can significantly reduce the time delay caused by traffic being looped back to the source node due to a fault on the network's primary path.